nodejs/src/types.ts:1108

• This overlay only updates the standalone type and PermissionHandler; the public SessionEvent/PermissionRequestedData types still come from the generated schema, where permissionRequest lacks this property. Consequently, an event-only host (the documented path when onPermissionRequest is omitted) cannot compile event.data.permissionRequest.managedApprovalRequired even though the runtime sends it. Please overlay the permission.requested event payload as well so every public permission-request surface exposes the metadata.

export type PermissionRequest = GeneratedPermissionRequest & {
    readonly managedApprovalRequired?: boolean;
};

nodejs/src/types.ts:1145

• The behavior change leaves the public README inaccurate: nodejs/README.md:39, :133, and :856-866 still describe approveAll as allowing every request/tool call. With a managed request it now returns no-result, so following those docs can leave execution pending until the consumer explicitly resolves the permission. Please update the permission-handling docs and examples to describe this exception and how hosts should resolve it.

export const approveAll: PermissionHandler = (request) =>
    request.managedApprovalRequired ? { kind: "no-result" } : { kind: "approve-once" };

nodejs/README.md:869

• The immediately following custom-handler example still returns approve-once for every non-shell request without checking managedApprovalRequired. Copying it therefore auto-approves managed Read, Edit, or Domain asks, contradicting the human-approval requirement documented here. Update that example to route flagged requests through a human confirmation flow (or leave them unanswered).

For requests with `managedApprovalRequired: true`, `approveAll` returns `{ kind: "no-result" }`. The request remains pending and the host must present a human-facing confirmation flow to resolve it explicitly.

• go/rpc/zsession_events.go: Generated file

• go/rpc/zsession_events.go: Generated file

java/src/main/java/com/github/copilot/rpc/PermissionHandler.java:60

• APPROVE_ALL now returns no-result, but Java's protocol-v2 dispatch path explicitly rejects that value: RpcHandlerDispatcher.handlePermissionRequest lines 222-237 throws and then sends DENIED_COULD_NOT_REQUEST_FROM_USER. Consequently a managed request is denied rather than left pending for a human decision. The dispatcher must suppress the response for no-result (as the other SDKs do) before this handler can satisfy the documented contract.

    PermissionHandler APPROVE_ALL = (request,
            invocation) -> CompletableFuture.completedFuture(Boolean.TRUE.equals(request.getManagedApprovalRequired())
                    ? PermissionRequestResult.noResult()
                    : PermissionRequestResult.approveOnce());

• go/rpc/zsession_events.go: Generated file

rust/src/session.rs:1526

• This unwraps permissionRequest before constructing the public PermissionRequestData, changing extra from the full notification params to only the nested request. Existing handlers that read extra["permissionRequest"], promptRequest, or other top-level metadata will silently lose those values (the current E2E helper at rust/tests/e2e/permissions.rs:599-622 explicitly supports that shape), and it contradicts PermissionRequestData's documented “full params object” contract. Populate the new managed field from the nested value without replacing the existing extra payload, or explicitly preserve the wrapper for compatibility.

    let request_data = event_data
        .get("permissionRequest")
        .cloned()
        .unwrap_or_else(|| event_data.clone());

• go/rpc/zsession_events.go: Generated file

• go/rpc/zsession_events.go: Generated file

dotnet/README.md:805

• PermissionRequest is the generated base class and does not declare ManagedApprovalRequired; only the Shell/Write/Read/Url subclasses do (Generated/SessionEvents.cs:6928-7130). This custom-handler example therefore does not compile as written. Pattern-match the supported variants (as PermissionHandlers.cs does) before reading the property.

        if (request.ManagedApprovalRequired == true)
        {
            return PermissionDecision.NoResult();
        }

• go/rpc/zsession_events.go: Generated file

python/README.md:836

• This async example has the same union issue: several valid permission variants do not define managed_approval_required, so it raises before reaching the asynchronous approval logic. Guard the optional per-variant attribute as the built-in handler does.

    if request.managed_approval_required is True:

python/README.md:811

• The generated PermissionRequest union still includes MCP, custom-tool, memory, hook, and extension variants without this attribute. This unconditional access raises AttributeError when the handler receives one of those ordinary requests, so the documented handler fails instead of applying its kind-specific decision; use the same getattr guard as PermissionHandler.approve_all.

This issue also appears on line 836 of the same file.

    if request.managed_approval_required is True:

nodejs/README.md:881

• PermissionRequest includes variants such as MCP and custom-tool that do not declare managedApprovalRequired, so this direct property access does not type-check for the generated discriminated union. The built-in implementation already uses an in guard; the public example needs the same narrowing or consumers cannot compile it.

        if (request.managedApprovalRequired === true) {

• go/rpc/zsession_events.go: Generated file

• go/rpc/zsession_events.go: Generated file